Outdoor lighting system and method

ABSTRACT

An outdoor lighting system for illumination of an outdoor area, the system configured to provide dynamical control in the outdoor area, the system comprising: a plurality of luminaires configured in the outdoor area; a plurality of street devices connected with the plurality of luminaires; at least one remote processor; at least one secondary processor; a cloud to which the plurality of luminaires and the plurality of street devices are connected; and the at least one remote processor and the at least one secondary processor are connected to the cloud; wherein the plurality of luminaires and the plurality of street devices are controlled in a plurality of functional modes.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/603,249 filed on Oct. 7, 2019, which is a National Phase Applicationof PCT International Application No. PCT/IL2018/050418, InternationalFiling Date Apr. 12, 2018, claiming the benefit of U.S. ProvisionalPatent Application No. 62/484,948 filed on Apr. 13, 2017, which arehereby incorporated by reference.

FIELD OF THE INVENTION AND BACKGROUND

The current invention relates to an outdoor lighting system andspecifically to systems and devices used to illuminate streets, roads,parking lots, railways, and large outdoor areas. More specifically,embodiments of the current invention relate to lighting systems thatprovide both a lighting function and a processing platform havingconnectivity such as IP connectivity and connected elements.

In the specification and claims hereinbelow, the term “outdoor area”when used in conjunction with a lighting system is used interchangeablywith “public space” and is intended to mean streets, roads, parkinglots, railways, and any other extended outdoor area.

In recent years, several fields of advanced technologies madesignificant advances and gained large attention from global markets suchas: LED lighting; IoT/IoE-Internet of Things/Internet of Everything;Smart City concepts and applications; and cellular, Wi-Fi and otherwireless communications

The following are definitions of terms used in the specification andclaims which follow.

A “LED lamp” is a light-emitting diode (LED); a component assembled foruse in lighting fixtures. The word “luminaire” is used in thespecification and claims which follow to mean a lighting fixture, asknown in the art, and specifically a lighting fixture having at leastone LED lamp therein. The term “street light” and “street light” used inthe specification and claims which follow is intended to mean aluminaire which is typically configured on an elevated platform, suchas, but not limited to a typical lighting fixture pole.

LED lamps have a lifespan and electrical efficiency that is severaltimes superior to that of incandescent lamps, and significantly betterthan most fluorescent and high intensity discharge (HID) lamps; withsome LED devices capable of emitting over 100 lumens per Watt. The LEDfixture market is projected to grow by more than twelve-fold over thenext decade.

LED lighting is widely-applied for street lighting and many citiesworldwide have been changing their street lighting systems to LED-basedsystems. The reason for this fast adoption of LED lighting by variousmunicipalities is the dramatic energy savings of LEDversus-conventional-lighting, which approaches about 60-70%.

“Internet of Things (IoT)” has been defined as a global infrastructurefor the information society, enabling advanced services byinterconnecting (physical and virtual) objects based on existing andevolving interoperable information and communication technologies. IoTis typically the network of physical objects (or “things”) havingelectronics, software, sensors, and network connectivity embeddedtherein, enabling collection and exchange of data to and from theobjects. IOT allows objects to be sensed and controlled remotely acrossexisting network infrastructure creating opportunities for more directintegration between the physical world and computer-based systems, andresulting in improved efficiency, accuracy and economic benefit. Eachobject is uniquely identifiable through its embedded computing system,however the object is able to interoperate within the existing Internetinfrastructure. Experts estimate that the IoT will consist of almost 50billion objects by 2020.

“Things,” as used with IoT, refers to a wide variety of devices such as,but not limited to: heart monitoring implants, biochip transponders onfarm animals, electric clams in coastal waters, automobiles withbuilt-in sensors, or field operation devices that assist firefighters insearch and rescue operations. These devices collect useful data with thehelp of various existing technologies and then autonomously direct databetween other devices. Examples of such things in the current marketinclude, but are not limited to: smart thermostat systems andwasher/dryers that use Wi-Fi for remote monitoring.

“Smart city” or “smarter city” are cities using digital technologies orinformation and communication technologies (ICT) to enhance quality andperformance of urban services, to reduce costs and resource consumption,and to engage more effectively and actively with its citizens. Marketsectors which have developed smart city technology include, but are notlimited to: government services, transport and traffic management,energy, health care, water and waste services. Smart city applicationsare developed with the goal of improving the management of urbaninformation flows and allowing for real time responses to challenges. Asmart city may be more prepared to respond to an array of challenges, asopposed to one simple ‘transactional’ relationship with its citizens.Other terms that have used for similar concepts include “cyberville,“digital city”, “electronic communities”, “flexicity”, “informationcity”, “intelligent city”, “knowledge-based city”, “MESH city”,“telecity”, “teletopia”, “Ubiquitous city”, “wired city”.

“Wireless communications” is intended to mean widespread means forconnecting people, vehicles and elements in a cost-effective way. Thesemeans include, but are not limited to: cellular (e.g. 3G, 4G, 5G),Wi-Fi, LWPAN, V2X, V2V, V2I, 802.11p, DSRC, Zigbee, RF, UHF, VHF,MicroWave (MW), Li-Fi, Free Space Optics (FSO), SATCOM, any type ofnetwork topology-mesh, star, point-to-point, and any operator,technology, and protocol spectrum.

In some cases, the communication to at least some lamp posts is providedby fiber or similar wired connection and the term “connected”, isintended to include both “wireless communication” and “wiredcommunication” in this context.

Traditionally, streetlighting systems incorporating LED or othertechnologies, are used to illuminate roads and sidewalks. Usuallystreetlighting systems are used with a singular on/off option. Recently,with the introduction of LED technology, remote control and some dimmingfunctionalities have been added. In parallel, cities, governmentagencies and various service providers have improved in and out-of-homeservices, municipality services, communication services or others,integrating multiple smart city systems, sensors, data, and logic, aswell as private sources, commercial systems, end user use of theservices and devices, and any other user or potential user of the publicspace. Such improvements and applications include autonomous vehicles,drones, smart billboards and other IoT devices and their respectiveservice provider networks.

All of these functionalities must be performed securely, protecting userdata and privacy, and in a timely fashion, integrating relevant data andsystems in a timely and cost-effective fashion. In this environment,there is a plethora of sensor meters and other IoT devices, such asluminescence sensors, air quality sensors, parking sensors, motionsensors, climate sensors, humidity sensors, radiation sensors, speedingsensors, visual sensors, radar sensors, acoustic sensors, fire sensors,and others. Additionally, there are multiple applications, applicationproviders, and service providers. Some of the service providers areassociated with single sensor/application, IoT, autonomous andcommunication devices, and some are not associated with any. This meansthat, for example, a weather-related information service providerinstalls its IoT sensors in the public space, usually collects thesensor data on its own network, or uses its communication devices andprocessors and processing environment being associated with his ownsensors pays for communication, processing and maintenance. The serviceprovider usually processes and uses its own data. This is done mostly ina central location such as the cloud. Such a reality presents manyproblems that impedes an evolution of the smart city and a coherent,optimal utilization of resources and wholesome services to public spaceusers.

Additionally, it is challenging to introduce new sensors or otherdevices into the public area and, even more so, to introduce newapplications that use such new and existing/deployed devices. Todaythere is typically virtually no sharing of resources, which results inhigh cost, low resource utilization, and a fragmented rather than aholistic approach and solutions for the public space. Aholistic/integrated approach integrates data from multiple relevantsensors, whether being co-located or distributed, to integrate logic anddecision-making by several different systems, vendors, providers andindividuals, to share resources as much as possible including streetprocessing power and communications, and to reduce communications andcost by data processing on streetlights or similar public-spaceinstalled processors connected on the network, integrating data anddecisions at the street-level on the local processor. This approachenables improved decision locally, as well as reducing communication,latency and faults, costs and use of cloud processing resources. Thisallows multiple operators, vendors and applications providers to runtheir applications on a standard processor using standard tools forsoftware development and software deployment such as the common AndroidOS, standard software languages, and App store paradigms to authenticateand deploy applications while sharing street-deployed sensors andplatforms.

There is therefore a need to resolve such problems by allowing multipleprocessing devices to use one another's IoT and sensors; to sharedecisions and data and to coordinate their actions-all at the street orneighborhxxl local environment, rather than having to transmit all theinformation to some central cloud location and back to the field.Further, there is a need to allow using the streetlight in many waysbesides a simple on/off/dimming street/road lighting. There is a needfor a system to allow lighting to be responsive to various conditionsand decisions according to multiple sensors, softwares, andapplications, passer-by requirements/impacts, IoT devices, autonomoususers of the public infrastructure, or others-either installed orassociated with the same streetlight (such as Edge Computing) and/orwith others, in a decentralized or centralized way as best fit toreduced latency, increase resource utilization, reduce costs andincrease serviceability and forward compatibility with additionalsoftware or applications or IoT devices being introduced to thestreetlight or to the public space. For example, solving the problemsnoted hereinabove may contribute to preventing road accidents withhuman-driven or autonomous vehicles by responding to changing conditionssuch as weather, fog, traffic, pedestrian movement, prediction of suchbeing based in AI, or other parameters and either informing the vehicleor driver in-advance and/or dynamically adapting the lighting of asingle or multiple streetlights or other sources of light or otherwaveforms or frequencies in coordination to better alert the road usersto any specific hazard. It may improve the lighting conditions or otherwaveform illumination conditions to specific needs or autonomousvehicles sensors in different distances or directions or shadingconditions or others. It may help protect assets in the streets. Theseare just a few examples currently not resolved and which could beaddressed in a standard-based platform, App-store deployment, andmanagement manner.

SUMMARY OF INVENTION

According to the teachings of the current invention, there is providedan outdoor lighting system for illumination of an outdoor area, thesystem configured to provide dynamical control in the outdoor area, thesystem comprising: a plurality of luminaires configured in the outdoorarea; a plurality of street devices connected with the plurality ofluminaires; at least one remote processor; at least one secondaryprocessor; a cloud to which the plurality of luminaires and theplurality of street devices are connected; and the at least one remoteprocessor and the at least one secondary processor are connected to thecloud; wherein the plurality of luminaires and the plurality of streetdevices are controlled in a plurality of functional modes.

Preferably, at least one of the plurality of luminaires is configuredwith elements comprising: a processor/computer configured to processlighting related functions of at least one lighting-related element; anApp Engine connected to the processor/computer; power related elementsconnected to the process/computer and to the at least onelighting-related element; communication elements connected to theprocessor/computer and power related elements; and internal sensorsconnected to the processor/computer and to the at least onelighting-related element, wherein the luminaire is configured tointeract with external communications elements; electromechanicaldrone-related elements; and external sensors and associated devices.

LIST OF FIGURES

The invention is herein described, by way of example only, withreference to the accompanying drawings, wherein:

FIG. 1 is a diagram of an outdoor lighting system and its elements, inaccordance with embodiment of the current invention;

FIG. 2 is a block diagram of the luminaire device shown in FIG. 1, inaccordance with embodiments of the current invention;

FIG. 3 is a diagram of a network of outdoor lighting systems, includinga main control and management systems (CMS) and a third-party CMS, inaccordance with embodiments of the current invention:

FIG. 4 is a block diagram of an LED failure compensation and powerstabilization mechanism, in accordance with embodiments of the currentinvention;

FIG. 5 is an isometric representation of an exemplary luminaire and itsoptical elements, in accordance with embodiments of the currentinvention; and

FIG. 6 is a schematic representation of two exemplary drone-systemconfigurations, in accordance with embodiments of the current invention;and

FIG. 7 is a block element diagram detailed view of the enhanced dronestationary pedestal shown in FIG. 6, in accordance with embodiments ofthe current invention.

DETAILED DESCRIPTION

The current invention relates to an outdoor lighting system andspecifically to systems and devices used to illuminate streets, roads,parking lots, railways, and large outdoor areas. More specifically,embodiments of the current invention relate to lighting systems thatprovide both a lighting function and a processing platform havingconnectivity such as IP connectivity and connected elements.

The system described is a pillar (also referred hereinbelow as“streetlight”) which connects and enables the creation of connectedstreet, connected city, connected person, connected vehicles andconnected elements that surround the inhabitants of the urbanenvironment of the future.

Embodiments of the current invention, as described herein, are relatedto the above-mentioned elements (i.e. LED lighting, IoT, Smart city, andconnected person-streets-elements concept described hereinabove). Basedon a LED street light solution and adding to it the benefits ofcomputation and connectivity in a unique architecture, embodiments ofthe current invention enable transforming existing urban electricity andlighting networks into a new and flexible platform providing smart andinnovative solutions to cities and urban areas and their living andmechanical inhabitants.

Reference is currently made to FIGS. 1-2, which are diagrams showing anoutdoor lighting system 10 and its elements, in accordance withembodiment of the current invention. Outdoor lighting system 10includes: a plurality of luminaire devices 12 (also referred to as“luminaires” and “street lights”); a plurality of street devices 14(such as, but not limited to drones, vehicles, pedestrians, mobiledevices, IoT devices, and advertisement boards), at least one remoteprocessor 16; at least one secondary processor 18 (such as, but notlimited to: an app provider, a service provider, and a data processor);and a cloud connectivity 20 (also called the “cloud”, as known in theart). Street devices 14 are connected with luminaire devices 12, asindicated in the figure, by an array of methods including, but notlimited to: single or multiple wireless or wired connections, cellular,Wi-Fi, LWPAN, Zigbee, fiber, satellite, mesh, star, and point-to-point.The remote processor and the secondary processor are connected with thecloud, as shown in the figure.

FIG. 2 shows a block diagram of luminaire device 12, shown in FIG. 1, inaccordance with embodiments of the current invention. Luminaire device12 includes: a processor/controller 30; an App Engine 31 (which includesa processing element/general purpose computer which may run a standardoperating system (OS)); power related elements 32; lighting-relatedelements 34; communication elements 36; and internal sensors 38.Luminaire device 12 interacts, as shown in the FIGS. 1 and 2, optionallyand/or alternatively with external communication elements 40 (such asbut not limited to: the cloud, communication concentrators; and acontrolled-mesh network); electromechanical drone-related elements 42;and external sensors and associated devices 44. Additional functionalityof App Engine 31 is described further hereinbelow.

Alternatively or optionally, part of or all of the elements shown inFIG. 2 within luminaire 12 may be configured outside of/remotely toluminaire 12, mutatis mutandis.

In one embodiment of the current invention, luminaire device 12 isimplemented within an electromechanical device or POD/enclosure thatcontains electromechanical and communication modular interfaces toexternal devices such as elements 40, 42 and/or 44 in FIG. 2 (suchinterfaces are depicted as thick arrows in the figure). Furthermore,device luminaire 12 contains all or part of the elements depicted withinthe luminaire. For example, luminaire 12 can contain elements 30, 31,32, 34, 36, 38, or any part thereof, with lighting-related elements 34not integrated within luminaire 12.

Processor/controller 30 serves to process lighting related functions ofone or more lighting-related elements 34. Processing functions include,inter alia, any combination of:

-   -   receiving lighting or luminance related data from one or more        lighting related external sensors 44 of one or more lighting        elements such as LED arrays;    -   obtaining input data related to power related elements 32, such        as but not limited to: power or power consumption or        amperage-related sensors of one or more power meters, power        converters, power drivers, power readers, and power related        circuitry;    -   obtaining input from internal sensors 38, such as, but not        limited to: thermocouples, mechanical steppers, other mechanical        or electro-mechanical engines, moving parts, sensors and        actuators:    -   obtaining input data from external sensors and associated        devices 44, which includes, but is not limited to sensors for:        time (ie a clock), GPS, ambient lighting, ambient temperature,        humidity, air pollution, noise, acoustic, smoke or other gas        sensors or analyzers, humidity, movement, cameras of any sort,        LIDAR, radar, wave detector, electro-magnetic radiation,        chemical or material related sensors/analyzers, electronic,        magnetic, bio-sensors, such as heart beat monitors or        light-based monitors, or any other sensor delivering raw or        processed information such as with video analytics or fused        sensory information or others, in real or not real time;    -   processing the data described hereinabove, taking into        consideration historical information and decisions; and    -   setting system parameters accordingly.

Examples of setting parameters include:

-   -   Setting power related elements 32 (such as an LED array) which        yields a given illumination level, illumination color, hue, etc;    -   Setting lighting-related elements 34 (such as mechanical or        electrical elements that affect the lighting angle of each LED        array);    -   Basing a decision to set lighting parameters on desired levels,        hues, colors, angles etc. at one or more ambient conditions,        where the at least one processor considers current conditions        against desired condications and dynamically adapts settings to        closely follow rules given or deduced from desired        specifications for current conditions;    -   Considering any information of internal sensors 38, such as when        the internal temperature exceeds a certain level, at least one        processing element reduces the power down by “X” to reduce the        temperature, for example, in accordance with a plan for lighting        longevity, rather than maximal lighting, at any given time (such        as at times of minimal traffic at that location or in general),        etc. The at least one processing element takes into        consideration priorities of respective lighting arrays according        to desired lighting functions, ambient conditions etc.

In addition to the block-elements identified in FIG. 2, luminaire device12 includes electronic circuitry connected to processor/controller 30and App Engine 31 and includes an algorithm which serves to monitorchanges in the circuit behavior, such as those from input or outputcurrent or power levels to deduce changes in the luminaire device. Suchchanges impact relevant parameters to achieve desired performance, sucha, but not limited to: maintaining stable lighting level over time;compensating for malfunctions or failed LED elements; and changing powerlevels.

Monitoring and changing parameters can serve, for example tomodify/replace conventional pre-set compensation mechanisms used inadvanced luminaires and LED drivers, which are currently based on futureestimations/projections, by an accurate, responsive and more efficientmechanism having incidental minimal addition cost to the system—asdescribed hereinbelow. Additionally, monitoring and changing parameterscan be applied, combined with a multi-channel LED array and separatedrivers for each channel, where there can be cross-channel compensationfor malfunctions. Finally, the parameters can be applied to changeillumination characteristics to suit changing operation conditions (e.g.change color in case of fog).

Reference is currently made to FIG. 3, which is a diagram of a networkof outdoor lighting systems 50, including a main control and managementsystems (CMS) 52 a and a third-party CMS 52 b, in accordance withembodiments of the current invention. Apart from differences describedbelow, luminaire devices 12 a, 12 b, 12 n and 12 x indicated in thecurrent figure are identical in notation, configuration, andfunctionality to luminaire devices 12 shown in FIGS. 1 and 2. Maincontrol and management system 52 a collects data from some or allluminaires 12 a, 12 b . . . . 12 n. The network further includes aconcentrator 55, which is an optional component, acting as a gateway orproxy or router for the communication with/to several luminaires 12. Insome embodiments, Either by polling or querying them or in an un-polledconfiguration, initiated by the luminares themselves, one or more at atime, or by concentrator 55, or by another trigger such as third-partyparty application, such as in third-party CMS 52 b. In some embodiments,CMS 52 a manages lighting functions of at least one of luminaires 12 a,12 b . . . 12 n . . . CMS 52 a starts or stops or dims or optimizes orapplies any pattern of lighting or program lighting, downloading to theat least one of luminaires 12 a, 12 b . . . 12 n, activating,deactivating, manipulating, configuring or otherwise monitoring andcontrolling the luminaires. In some embodiments, CMS 52 a is configuredto monitor or control functions, software, applications, hardware orother components of one or more of the luminaires. Such management andmanipulation and control may be based on the data or the function of asingular luminaire, for example 12 a, being managed at a given instant,The management and manipulation is also done in coordination withfunctions or activity of other luminaires, or their control ormonitoring by CMS 52 a. For example, CMS 52 a may instruct or command inreal time or offline luminaire 12 a to illuminate at a specificlamination level if a motion detection sensor of an adjacent smartluminaire, e.g. 12 b, reports detection of a motion. Alternatively oroptionally, CMS 52 a controls lighting functions of luminaires 12 a and12 b to direct their respective lighting beams at certain angles and/orto control respective optics, dimming and/or lighting hue or lightspectrum and/or intensity and/or any other attribute, so that theluminaire combined lighting at a certain point on the road or sidewalksatisfies certain conditions or requirements, such as, but not limitedto eliminating shades or escorting a moving vehicle. Further, CMS 52 ainforms inform third parties such as CMS 52 b, or publish, rand receivethird-party requests, or to receive software and applications fromthird-parties, or function calls to initiate authorized activities to berun by CMS 52 a or to be directly run by luminaire 12 a, inter alia.

In some embodiments, third-party applications or software or data isdownloaded into at least one of luminaires 12 a, 12 b . . . 12 n in asynchronized and guaranteed manner. This is done either via CMS 52 aand/or via a third party cloud 20 b, if authorized first via CMS 52 afor at least one luminaires 12 a, 12 b . . . 12 n according toauthorization schemes and database and service agreements associatedwith CMS 52 a

In some embodiments, at least one of luminaires 12 a, 12 b . . . 12 ncommunicate with at least one other luminaire, for via concentrator 55as a communication proxy, yet without proxying or involving CMS 52 a orany other centralized CMS (not shown in the figure). Respectiveluminaires trigger communications, send sensory or other data to any ofthe other luminaires in a given communication group, receive data orother information from any other luminaries, request an application orsoftware to execute certain functions, conditionally or unconditionally,coordinate the at least one luminaire operation of some of its functionsor hardware in concert or according to the data or timing or otherparameter relative to any of the other luminaries. CMS 52 a is informedof such communications CMS 52 a optionally or alternatively intervenes,confirms, dis-approves, and remains “transparent”/non-intervening perits programming.

In some embodiments, sensory information from at least one of luminaires12 a, 12 b . . . 12 n one smart luminaire may be sent to otherluminaires which either have or do not have a similar sensor installedor associated therein. Such information triggers the luminaire activityor functions therein. Alternatively or optionally, the information isfused or combined with other sensors or other information or otherconditions or software instructions to generate activity or control offunctions in any of the luminaires. Such fusion is done at least one ofluminaires 12 a, 12 b . . . 12 n, or at the CMS 52 a for at least one ofluminaires 12 a, 12 b . . . 12 n, or in both the CMS and theluminaire(s)—as a distributed processing and decision making and controleven for the respective luminaire.

Reference is currently made to FIG. 4, which is a block diagram showinga controller 80 (which includes an algorithm, not shown in the figure)for LED failure compensation and power stabilization mechanism withassociated elements and electronic circuitry, in accordance withembodiments of the current invention. In one embodiment of the currentinvention, controller 80 forms part of processor/controller 30 describedhereinabove in FIG. 2. A power source 82 (typically mains power)provides power to a controllable LED driver 84. Controller 80 receivesexternal control commands and/or the controller is preloaded and pre-setwith a set of desired operational parameters. The controller isconnected to a power monitoring module 81, receiving power parameterssent from the power monitoring module. Examples of power parametersinclude but are not limited to: input power, current, and voltage.

The controllable LED driver 84 receives control commands from controller80. An open circuit protected LED module 86 receives DC power from thecontrollable LED driver 84.

The controller 80 and algorithm monitors changes in the behavior of thecircuit, such as in the input or output current or power levels todeduct changes in the luminaire. As a result, controller changesrelevant parameters in order to achieve a desired performance-such asmaintaining stable lighting level or power level over time orcompensating for malfunctions or burned LED elements in the LED module;or changing power levels etc. (as pre-set, and/or defined by externalcontrol).

Controllable LED driver 84 and LED module 86 may represent amulti-channel LED array and separate drivers for each channel, where thedescribed circuit can provide cross-channel compensation.

The described circuit has also the ability to automatically changeillumination characteristics of the LED module to fit changing operationconditions (e.g. change color in case of fog).

The verification process 88 described above, occurs continuously, andprovides power adjustment and compensation to changes in parameters asdetected received from the monitoring device 81.

Further functionality of controller 80 is discussed hereinbelow.

Reference is currently made to FIG. 5, which is an isometricrepresentation of an exemplary luminaire 150 and its optical elements,in accordance with embodiments of the current invention. The exemplaryluminaire includes the following exemplary optical elements; a LED metalcore printed circuit board (LED MCPCB) 152; a plurality of LED's havinga primary optical lens 154; a plurality of optical reflectors 156; and aplurality of heat sink fins 158.

As shown in the figure, the optical elements are part of a set of aplurality of reflectors and lenses, along with a group of LED elements.The elements can be modified and set to create different illuminationpatterns, as known in the art.

The luminaire (composed of the optical elements) is connected to acontrol element (such as part of processing and storage elements 30, asdescribed in FIG. 2 hereinabove) which modifies the illumination levelaccording to any of number of road and environment variables listedhereinbelow. The luminaire is connected with an on-ground unit, or asensor/processor (as part of external sensors 44, as described in FIG.2) that serves to analyze road characteristics and data and conveys arequired illumination pattern to the controller within the luminaire.

A network of luminaires-such as shown in FIGS. 1 and 3 hereinabove—canbe controlled according to the above data and can be dynamically andadaptively adjusted to optimally fit the road scenario, including suchas, but not limited to: changing weather conditions (i.e. snow, fog,haze and off-road reflection); traffic density; type of traffic; ambientlighting changes (ie other lights, moon, sun, etc.) air qualityparameters; pollution state; and measured or predicted or anticipatedconditions according to historical data or pre-configured or currentlyreported conditions or parameters or other heuristics or derivative ofmeasurements or learning machine (Artificial Intelligence) or any othermathematical prediction function, from a respective streetlight'ssensors or processing elements and/or from other streetlight sensors orfrom other resources or any combination of such.

Maintaining a desired level of illumination for a target area isperformed by employing an automatic mechanism (having both hardware andsoftware components) to both actively maintain the desired illuminationlevel and to overcoming individual diode burnout or outputdegradation—as indicated in FIG. 4 hereinabove.

In addition to the power input level measurements described above, thefollowing embodiments are optional or alternative:

-   -   Measuring actual lighting levels at or near the target area by        direct measurement of the actual illumination. This is very        accurate in terms of measuring the actual illumination level        versus a desired one, rather than deducing the level from some        source/generator/engine measurements. Such direct measurements        may include: marks/markers being configured near objects in the        desired illumination target area. For example, one or more        signs, images, colors, strips, shapes or reflecting objects such        as poles, lighting “cat eye” etc. are configured on a road,        pavement, lamp post, house wall etc. (This type of measurement        is analogus to in similar fashion to a manual “eye check”        performed by an optometrist.)    -   Incorporating other markings (as described hereinabove) to        include non-specific and non-specially designed objects that are        already part of the scene. Examples include, but are not limited        to: parking-related markings on the curb; a fire hydrant; a        detail of a bus station; and a wheel of any parked car.    -   Such measurement can require a learning pattern or calibration        process. Exemplary patterns can include, “measuring” during full        daylight of a grid, or scale of colored or black-white strips or        other shapes marked with special colors and/or different strip        properties such as size or color or reflectivity, and comparing        the measurements to those performed at nighttime, or changing        the illumination level and measuring until an optimal result is        obtained and then maintaining it stable, etc.

An algorithm used in such an illumination processor (ie “engine”) caninclude measurements to remove false readings. For example, an image onthe road may be partially or fully blocked due to a passing or parkingcar or another object. The processor learns these patterns, comparesthem to other information (such as data from the lighting source such asan illumination sensor at the engine or measuring the temperatureassociated to the lighting panels or the input power to it) etc.

Optionally or alternatively, embodiments of the invention includemarkers, or dedicated sensors, configured at the target illuminatedarea, having a short-range transmitter to transmit illumination databack to the lighting engine, hence closing the loop.

As noted hereinabove in the description of FIG. 2, as part ofcommunications elements 36, a connectivity module, based on technologiessuch as, but not limited to: Zigbee, LOWPAN6, Wi-Fi, Cellular, Fiber,mesh, proprietary, PLC, and any other, IP-based connectivity isconnected to processing elements 30 (ref FIG. 2). Information to andfrom the luminaire is transferred to/from remote processor 16 (asdescribed in FIG. 1), such as a network control center/server, networkoperator a remote unit. Remote processor 16 is part of externalcommunications elements 40, as described in FIG. 2 hereinabove. Suchinformation can additionally include software modifications/upgrades anduser/system commands—as well as information from the current luminaireto other luminaires and/or sensors. Lighting levels are coordinated whenthe current luminaire is in communication with adjacent luminaires.

Additionally, connectivity of the luminaire includes connectivity with:a remote App-store or similar offering relevant applications includingfrom certified 3rd parties; passers-by such as connected cars;pedestrian smartphones; smart meters such as utilities meters (water,electricity, gas, . . . ); “Smart City” elements such as cameras andother sensors or processing elements; traffic lights and traffic control(including the possibility to involve algorithms and logic of theprocessing elements in the luminaire to control the aforementionedelements. Other possibilities include: functionality as a communicationproxy (including as router or repeater) between other processors,sensors etc. and same or other remote servers; providing wirelesscommunications hot spot or connectivity (Wi-Fi, LTE or other); providinga backhaul communications link (from users to the cloud or centralcommunications network; for “last-mile” communications) to bedistributed to residential or office locations, including performing orfunctioning as a “concentrator” or “aggregator” for many IoT devicetypes and devices. In such cases, connectivity can serve to providepre-processing services for these devices and their information, forexample compressing their data for a lower volume communication thussaving cost, power and time and accommodating more IoT devices tocommunicate, or to extract the more important or relevant information.

App engine 31, described in FIG. 2, is an optional additional processingelement that runs typical consumer-grade or telco-grade orenterprise-grade Operating Systems (OS) such as Android, Linux, AppleiOS, Windows, Chrome etc. The processor thus runs generic orplatform-specific software applications and uses special barriers toprovide isolation from lighting processing elements 30 (of FIG. 2) inhardware and/or in software to minimize potential impact of applicationson lighting, such as: overloading the lighting processor; harmfulcontrol of the power drivers or any other lighting-driving or sourcingor service affecting; sending rouge incorrect commands as if coming froma valid remote management system or user; hardware means may includephysical identification whereas software means may include softwareabstraction layer, APIs, certification mechanisms such as Radius, HTTPS,encryption-based, proprietary, or others.

The App Engine allows certain verified communication and control overthe luminaire or luminaire-related and other peripheral systemscontrolled by the luminaire processing system to communicate with thelighting processing element, so that:

-   -   Lighting/lamp related information that is valid to be exposed to        external applications is thus exposed, or is made available.        This can be further exemplified by the way GPS or gyroscope or        other sensors in a smartphone are handled by the OS, APIs and        Apps. Similarly, the lighting or lamp-related hardware, mainly        luminaire related and luminescence related sensors, optics        electro-mechanical controllers, actuators or dimmers, may be        incorporated to existing OSs and such as Android or iOS or        Windows, require authorization for each Application to access,        see or handle them, share their info with other applications or        softwares etc.    -   Valid commands that may impact the lamp performance in permitted        applications and scenarios (e.g. an application that is run on        the App Engine, for identifying free parking spot by utilizing        external vision systems, for example, which causes a change in        illumination to signal to a connected car, directing it to the        available parking location), or motion detection, or thermal        detector, or any other sensors, or combination thereof.

The term “generic application” is intended to mean an application, orsoftware, that was not designed especially for the luminaire platform,meaning applications that can be typically downloaded from an app storefor Android Operating Systems (OS) or iOS or Windows or others. Anexample includes a ride-hailing application for sensor monitoring orsharing application or a video analytics software or an availableparking detection application. The generic application may have beenadapted for the described platform or processor similarly to adaptationof applications or softwares for them to run on specific hardware orversion of Operating System (OS) or work with a specific set of sensorsor other hardware components or drivers or similar.

The App Engine further:

-   -   Receives input from any sensors such as ambient temperature,        ambient air pollution/quality, humidity, rain, wind, smart        meters, passers-by smartphone carrying a multitude of sensors,        connected cars sensors etc.;    -   Runs an application, alone or coordinated or distributed with        other lighting lamps and processors or external elements (such        as said smartphones, cars, connected wearables, etc.) that        provides lighting to physically impaired passers-by, such as        people with eye conditions, old, drunk, or on-contraire-people        that move fast and need relevant lighting such as joggers;    -   Runs streetlight an application that identifies        driving-under-the-influence or otherwise hazardous driving, such        as for example according to the flash-light and/or tailgate        lighting movement patterns of the car, or of the car itself,        either in the processing element or remotely or in an attached        camera, or when sharing raw or processed data or other        information or decision making with other processors or        streetlights and then alerts authorities, alerts passers-by even        including such that are in the route of the vehicle and are        under the area controlled by another lamp or communication        device, change the lighting conditions on this lamp and/or        others to (a) alert such passersby more vividly and/or (b) adapt        the lighting available to the driver of such vehicle so to try        and minimize hazard by him/to him, for example by increasing the        light in his route more than the standard strength provided for        regular or normal drivers on that street, or adapting the angle        of the optical element or elements in this streetlight and/or in        others that are in direct communication with this processor or        via the cloud or another processor;    -   Runs static, dynamic or reactive or interactive advertising,        which may in connection to interaction with other sensors,        connected cars, smartphones, etc, or information from the cloud,        the control center or other luminaires. Advertising information        may be streamlined or downloaded from afar, or stored locally        and used according to a decision of s/w residing in the App        Engine. The displays may be either attached to the luminaire or        the pole or remoted from it yet with communication to it, for        example billboards, walls of buildings or others. In some        embodiments, the processor may coordinate special lighting        effects to the content displayed. Then adding dependencies as to        the color, strength, angles, and timing, as well as to        “escorting” viewers such as cars and pedestrians with the right        combination of light from the multiplicity of streetlights onto        a building wall that is used as a billboard or display. This may        minimize the electricity costs for the building wall or a bus        stop advertisement operator as lighting will be        operated/enhanced only when “sufficient” or “good enough”        viewership is determined.

Further, the processor can coordinate the lighting colors and strengthand angles and any other parameter to the content displayed, so forexample, the higher part of the building is illuminated in a certainpattern while the lower or middle parts in different patterns, or when aspecific image or text is displayed a pre-designed or learnt lightingpattern is directed to illuminate it, including from two or morestreetlights in its vicinity. Or, the lighting angles may change as theprocessor controls the electro-mechanical or optical elements in theluminaire, in coordination and synchronization with the content beingdisplayed, or the viewers angles, or other streetlights luminaires, sothat, for example, a 3D depth viewing is achieved when viewing from aspecific location or angle or direction, from a 2D display, or a wall orsimilar.

Above includes warning signs, road and pedestrian notifications, controlof projection or display means or signaling elements, which are includedin the luminaire and controlled by the lighting controller or areseparate from the luminaire. Earthquake detection using any combinationof a multitude of detectors (that can be low-cost or less sensitive thanthose in use in professional earthquake detection stations) and specialreal-time and non-real time algorithms to analyze the incoming data;option/ability to fine-tune the detection and data as a response tocertain data analysis and scenarios.

Same as previous item for fire detection, pollution (including accurateper street/GPS location) reading and rating, noise levels, etc. The GPSor other location information from any of the onboard sensors orexternal sensors or received information can be shared with all runningApplications or softwares. Similarly, any other sensory information, orprocessed analyzed output of such, may be thus shared locally andbetween connected streetlights, if authorized.

In embodiments of the current invention, the streetlight acts as a“guard” (or “Light Watchdog”) for vehicles or other property, peopleetc. An example is anti-theft parking. When the connected car is parked,and anti-theft app is activated, an app running on-board the car sendsperiodic beacon/keep-alive/of the signals. The closest smart streetlightmonitors the signal, so that if the signal changes, the vehicle owner orpolice are alerted. The app start/stop may be performed by the car or bythe owner smartphone app, which is better because maybe it's moredifficult to counter-fit. Similarly, the monitoring is performed donevisually, via video analytics such as identifying “violent penetration”patterns or in the case of vehicles-moving from one area to anotherwithout the app being stopped first (so that there is no need for aconnected car constantly transmitting-a simpler FIR or similar sensormay be able to do the job and there may be no need for a camera).Similarly, the application may be applied to prevent theft of bicyclesand motorcycles, etc. Similarly, the streetlight processor and sensors,from same streetlight or connected ones or additional sensors, canmonitor against arson or vandalism of monitored elements such asvehicles, shops, buildings etc.

Embodiments of the current invention include a device, system and methodto watch against auto-theft and/or abuse, vandalism or any otherundesired activity.

Embodiments of the current invention employ a logical “locking”mechanism that is triggered on/off (or enable/disable) either by a useror automatically by the device being monitored or from remote. Thus, theinvention allows a new method of watching and safekeeping-pay-per-watch,or subscriber-based, without any installation in the monitored object.

Current methods such as used for monitoring vehicles against theft orvandalism typically use a device being installed in them, such as aGPS-based processor being used to monitor its own movement and sendalerts over an installed cellular modem, etc. These methods are ofcourse more complex, cost more, depend on installed equipment (such asits health and well-being and no faults), depend on the service providerof that installation, the health of the cellular modem, notjamming-proof, cost more, need to install the device in a hiddenlocation (which the thieves are many times quick to learn), notprotecting against vandalism such as exterior vandalism, arson, notsuitable for all types of objects (e.g. not suitable for bicycles) etc.The current invention overcomes all these shortcomings because no deviceor other equipment or software are being installed in the monitoredobject.

Embodiments the current invention include at least one monitoringelement (ie “sensor” as part of external sensors 44, described in FIG.2) that is installed within an outdoor device. It is implemented inhardware and/or software. It monitors the events in the street, parkinglot, roadside or any other outdoor space. The device has sensors and/ordetectors, such as but not limited motion/movement/visual detectionusing current technologies such as PIR (Passive Infra-Red), Infra-Red(IR), LIDAR, MW (Microwave), camera, area reflective such as infra-redemitted from LED, ultrasonic, light reflection sensors (where thedifferent reflection of light, such as emitted/generated by sun-lightand/or the streetlight LED luminaire, is reflected from surfaces in thestreet/open space and measured and differences are identified) or anyother passive or active wave-based or other detection motion of the openspace being monitored.

Sensors that form part of embodiments of the current invention aretypically installed inside or mounted in conjunction to the streetlighting devices such as the LED luminaire, the streetlight pole,mounting, cover, or on any other outdoor equipment, such as electricpole, telephone pole, cellular towers or antennae etc. The sensors maylikewise be mounted on mobile overhead platforms, such as drones.

In some embodiments, the apparatus included or associated with theprocessor, internal sensors, communication modem antennae or othercomponents, external sensors or interfaces to such, drone landing ordocking station or the other components in this invention, may beinstalled on other platforms or mountings. For example, on trafficlights, billboards, buildings walls or roofs, on moving vehicles, onships etc.

In embodiments of the current invention, a user that has a mobile device(such as a smart watch, wearable computer, smartphone, tablet etc.),triggers a “watching”/monitoring function in the streetlight or othernetwork element processing elements. For example, the user may park hisvehicle in the street. He then runs an application on his smartphone orpresses a button on his smart watch or on the vehicle processor userinterface. The user command is sent to the managing entity running onsome processor along with the location of the user and/or vehicle. Suchlocation may be based on GPS, cell ID (cellular or Wi-Fi), beaconingdata or any other. The information is then processed by the managemententity. It may inform relevant streetlight monitoring elements orprocessors that such a request was issued. It identifies “relevancy”according to location matching between the location of the user orvehicle (or other watched object that has location informationassociated with it), and the known location of the monitoring sensorsand/or processors. Even more so, a closer matching and more accurate onemay be done for specific locations using the information known about thecoverage area of each such sensor (such as area, angles, height,unmonitored areas etc.). More than one monitoring element may bealerted, for example if the monitored object (vehicle in this example)may be covered by sensors mounted on more than a single streetlight,such as subsequent streetlights or opposite-side streetlight etc. Theuser may then be given an indication that the monitoring has beenset/triggered (with or without a “delayed action” timer allowing him toget away from the monitored object without setting an alarm). Suchnotification/indication may be visual, audible, or other. The user, orhis processing device, may also be asked to perform a “handshake”procedure with the on-site monitoring element (or more than one), suchas to transmit a short sequence over Wi-Fi, cellular, Zigbee etc. Duringthis handshake, unique information may be passed securely from themonitoring element or the monitoring management element to the monitoredobject such that may be used during this subsequent watching period.Such information may include secure code or key that the object shalltransmit (ciphered/encoded or openly) during pre-establishedperiods/intervals or any other session related information to be agreedby both or commanded by the monitoring element. For example, a LED-basedvisual identification pattern (such as short flashing etc.). Informationmay also be sent securely from the monitored object and/or userapplication or device, during the triggering of the session, its set-up,or the handshake. Such information may include user or object ID,parameters about that, payment details, subscription details, uniqueIDs, keys, etc.

In embodiments of the current invention, the watching and monitoring ofthe object may be done by the sensor or sensors identifying “keep-alive”notifications done by the vehicle. All or part of these actions andalgorithmic steps may be done automatically. For example, the triggeringmay be done automatically, for example where the vehicle processoridentifies that the user/drive/owner smartphone or other processor orapplication has distanced from the vehicle (proximity based), with thedoors going locked and/or with other indication, so it automaticallysends such request to be monitored request to the watching managementelement. The handshake process is performed automatically by the vehicleprocessor, whether or not a driver is present, and/or by the mobile userdevice. An application on the user device identifies the user'spresence/absence from the vehicle and triggers a request for monitoringor any other portion of the process automatically or commands an objectprocessor to do so.

Similarly, the setting off of the monitoring session is also done eitherby the application on the user device and/or combined with the vehicle(or another object) processor. Either manually or automatically, such asupon the user getting into the desired proximity from the object.

In embodiments of the current invention a mobile “watcher” may bealerted. For example, a user who pays extra may call such a watcher. Orthe system may use it at random, or in areas where there is nosufficient coverage of statically mounted sensors on the streetlights,or if the said object is identified to be of more value or in areasrecently identified to suffer from higher crime rate or if the mobilewatcher (e.g. a drone) has nothing better to do at that time orloitering around, etc. Communicating with the mobile watcher is donealso via the same algorithms described above, and in concert orcoordinated with the cloud-based or other management entity and or thestatic sensors directly communicating with this mobile watcher for thatsession period.

The monitoring sensors may use “beam forming” to continuously watch overmultiple objects in its coverage areas, or a “scanning” pattern so itwatches over a limited number of objects (usually one) at any givenpoint in time and then moves on to watch another one, unless triggeredto stay watching the first one due for example to an event or suspiciousof event or prediction of events or another sensor in the network justnow monitoring the other (Second or other) object, when the sensors arecommunicating and coordinating their scanning or identification oralerting processes over local network (e.g Zigbee, 6LowPAN, vehiclecommunication protocols etc) or via the backbone (cellular, cloud),which is currently less effective or desired but sometimes necessary(such as if no local network or communication modems are installed onone of the sensors).

If more than a single sensor is watching over an object, and a handshakeis being utilized within the watching session, then any information ordata (such as unique ID or security keys) exchanged between one sensorand the object may also be exchange, as is or modified (such as used togenerate a new security key) also from the object to any other sensor,or between the sensors themselves.

One of the monitoring elements, or the monitoring management, maycommand a certain streetlight luminaire (or more than one), eitherlocally or from remote respectively, to light up or light in a certaindirection or at some specific area, in order to improve sensingcapabilities of some sensors, such as a camera or motion-based sensoretc.

The monitoring processor may then identify suspected conditions. Forexample, it may identify scratching sound (such as when someonescratches the paint of a vehicle), a breaking glass/window sound, aproximity of a person to the object, a sharp movement in the proximityof the object, a partial-disappearance of a person in the proximity ofthe object, a strong or other light-pattern associated with fire orarson attempt etc. It may also identify movement of the object. Suchidentifications may be done by a single watching sensor or inconcert/coordinated/validated/complementing by several of them, on thesame lighting luminaire of on different ones or with the mobile watcher.Similarly, the lack of any agreed periodic information (such as thebeacons, or WiFi messages or LED flashing patterns etc.), or itsfaultiness (e.g. diversion from the agreed patterns or data in themessages etc.).

The streetlight or other monitoring processor alerted to the suspicionactivity (such as breaking in attempt, stealing attempt, vandalismattempt etc), may respond by alerting the user via his connected deviceor any other means or any other person or entity (such as the police).It may alert a mobile watcher to come over. It may alert locally or overthe backhaul network instruct its own streetlight luminaire or anyothers to light up or down of increase or reduce or use different LEDcolors or move its LED light beams or sound alert via an installedspeaker or other audio device or any other pattern to deter thepotential hazard/intruder/vandalizer/unwanted activity and anyone elsein the vicinity. It may further use a “IoT-crowd/social” algorithm torequest other connected objects (either also being monitored orotherwise simply connected via the cloud with the monitoring managemententity or locally with the watching processor) that are in the vicinityto use their deterring means, such as vehicle lights, sirens, horns etc.so the whole vicinity becomes alerted. Of course, such social usage ofmultiple objects dramatically increases the impact of a watchingservice, its effectiveness and the cost/performance ratio of usingconnected objects. One device being randomly sufficiently co-locatedwith another device is watching over and that device, and/or alertingthe environment if so requested, either on a paid basis or voluntarily.

The service may further notify other people in the vicinity. Such peoplemay be registered in the management system as “watchers”, either payingfor their service or as volunteers.

In some embodiments, the streetlight communication network andcapabilities are used to continuously alert and signal the route of astolen object being carried or driven away. For example, streetlightafter streetlight may flash the LED lights, move their beams, turn themon-off in any desired pattern, light over the moving object etc so thatthe whole environment of the moving object is aware of that. It may alsoreport back on its movement and location. Such usage of the lights ispossible due to the LED-based luminaire capabilities of easilycontrolling the LED light strength, luminescence, number of LEDs beingused, direction of the LED, etc.

In some embodiments there is no communication with the monitored objectbut only with the user. For setting/triggering on/off the watchingrequest, reporting back to the user etc.

The streetlight watching processor may handle all local activitieslocally and communicate with the monitoring management when needed, anddirectly via local network or via backhaul with other streetlights inthe vicinity, with other sensors such as the mobile sensor in thevicinity or alerted even if remote, with local monitored objects, withlocal connected objects that are not watched over but “volunteer” orregistered to perform some activity on-demand such as alerting theenvironment using their means, with local or remote people or users orowners or entities such as the police etc.

In some embodiments, information such as consider information andcommands coming in over the communication element from any otherlighting processing element, sensors, or remote. Considering suchinformation may include the lighting levels at the adjacent lightingengine/lamp, so that a coordinated, synchronized, compensating, or othercorrelated lighting may be instructed. For example, a light bubble, orarea of interest, that is synchronized between several lighting engines,or polls, or beams. Synchronization may be over all the time or part ofthe time. It may coordinate the area of interest lighting level at thatspot, lighting color (that may be combined of severaldifferently-colored beams from one or more engines or arrays), hues,shade or lack of shade, patterns (such as flashing at a specific tempo),etc. The streetlight processors, or remote management system, mayfurther coordinate this synchronization so that the area being lighted,or shaded, is moved around dynamically such as to follow or light up formoving objects such as pedestrians, vehicles, autonomous vehicles etc.

Reference is currently made to FIG. 6, which is a schematicrepresentation of two exemplary drone-system configurations 160 and 170,views (a) and (b), respectively, in accordance with embodiments of thecurrent invention. System configuration 160 includes: at least one drone162; a pedestal (or “pole”) 164 securely installed in the ground or anadjacent building (neither shown in the current figure), a dronestationary pedestal mounted at the upper part of pedestal 164 and havinga mechanical drone retention mechanism 168.

System configuration 170 includes: at least one drone 162; an integratedelevator mechanism/pedestal (or “pole”) 172 securely installed in theground or an adjacent building (neither shown in the current figure),and an enhanced drone stationary pedestal 174 mounted at the upper partof pedestal 172. The elevator mechanism serves to convey packagestypically carried by the drone to and from the pedestal. Both systemconfigurations 160 and 170 include communications with cloud 20 and withthe at least one drone 162. Details of enhanced drone stationarypedestal 174 follow in FIG. 7.

Reference is currently made to FIG. 7, which is a detailed view of blockelement diagram of enhanced drone stationary pedestal 174 shown in FIG.6, in accordance with embodiments of the current invention. Pedestal 174includes: a drone beacon (for landing/guiding, including RF, optic,and/or light technologies) 176; streetlight engine processor (“streetlight processor”) and communications modules 178; at least one antennamodule 180; a power/communications wired connection for the parked drone182; an electromagnetic pulley/towing/locking mechanism and/or includingdrone induction charging 184; and streetlight-dedicated sensors(including environmental, lighting, visible, RADAR, and LIDAR) 188.Pedestal 174 is wire-connected to power and communications module 186,which is not located on pedestal 174. As noted hereinabove, pedestal 174is in communication with cloud 20 and with drone 162. The followingdiscussion details additional embodiments related to the elements ofFIGS. 6 and 7.

In some embodiments, the streetlight controller or processor maycommunicate with autonomous vehicles such as cars, drones, ships orothers, either directly or via a proxy, or be notified of theirwhereabouts or approaching. The streetlight may be equipped withvariable wavelength emitting sources, various LED types or otherradiating sources, optic or electrooptic filters, beam forming elementsetc. As the evolving sensors for autonomous vehicles may be optimallyworking with different ambient or road lighting or backgroundconditions, the streetlight processor may tune the emitting sources andoptics and beamforming to match the autonomous vehicle optimizationrequirements, to illuminate in different waves or wavelengths or poweror angles or wavelength changes or gradients between illuminated areasor patterns various objects or signs etc. For example, the streetlightmay illuminate the road sides in different power light or differentwavelength or color than the driving lane or the opposite direction laneor the adjacent lane or road shoulders, or the intersections or parts ofintersections, or the near field for a moving vehicle vs. the mediumfield or the remote field, or identified potholes or bumps or other roadobstacles or identified pedestrians or animals in the relevant vicinityof the road lane or other objects that may be of interest or ofassistance to the sensors and processors of the autonomous vehiclesdriving systems. Multiple streetlights or wave emitting sources may beused on conjunction or in synchronization to create the multi-wavelengthand volume or strength or power or amplitude different road or scenariosensory information for the autonomous vehicles.

Further, the processor and/or the remote management system may decide onlighting or illuminating decisions by optimizing shade or gradient ofillumination rather than the traditional lighting conditions. Thesensors may either sense the lighting level, or the lack of lightinglevel, at the desired lighting area of interest, or in the undesiredlighting area. Accordingly, the relevant processor may make a decision.For example, it may have, or learn, or otherwise set a desired targetfor the gradient change between light and shade (or darkness). Forexample, such gradient may be low or high gradient, i.e sharp or lesssharp edges and changes from lighted area to dark area. Another targetmay be that a minimal level of lighting, or maximal level of darkness(or shade) at any specific or all other areas. So that the whole streetis maintained at least, and/or at most, at a minimal lighting level at acertain point in time.

The relevant processor or processors may maintain the desired changelevels (or gradients) between shade (darkness) and lighting orillumination with other wavelength emitting sources at a certain levelwhen the lighted area is moved around such as following or heading themoving vehicles.

Similarly, desired level of gradients may be maintained between anyother parameter of the lighting or wavelength emitting source, such asdifferent colors, hues, reflectiveness, wavelength, power, angle etc

The relevant processor may generate a desired lighting level anddirection also according to parameters such as the reflectiveness of thesurface or surfaces as being measured. Such measurements may be doneonce, at calibration, or periodically, or continuously.

The additional processing element (App Engine, as described hereinabove)may be an attachable devise—as an “add-on” or “plug in” to theluminaire, with the needed mechanical and software interfaces availablein the system to allow straightforward and fast connection. The AppEngine can be assembled on a printed circuit board (PCB) or as anencapsulated PCB, which can be attached or plugged-in by a multi-pinconnector to the main board of the luminaire (which may contain theluminaire processing element and other components and modules describedabove), in a “blade” or a “micro blade” configuration. The luminairewill be operative without attaching the App Engine, and operative withenhanced (smart) capabilities when the App Engine module is attached,allowing it to run applications and perform the tasks described above.

In addition: a server running management software can:

-   -   Allow management and programming of individual lighting        elements/lamps, or groups of lamps, or of other lighting        electrical grid elements (e.g. electrical cabinets); collect        performance data, set alarms and notifications, produce        performance reports and data, etc.,    -   download SW upgrade, or a new complete application, to many        streetlights, automatically scheduled according to the field        deployment of the connectivity and of the processing elements        capabilities, in an optimized way so that wireless communication        congestion is avoided yet it is ensured and registered that each        relevant lighting (it's processor or App Engine) was properly,        or improperly loaded with it and running it, or retries, or        marked as non-functional for that application or in general;    -   Contain, manage, stamp, or otherwise impact “lighting-valid”        certifications to applications, so that lighting processing        elements can rely on this certification in order to allow such        applications to run on them, access their data, etc.;    -   In addition: A virtual representation of any planned or deployed        systems    -   Important especially when dealing with such mass deployments,        even more so as the platform needs to be protected from        failures, hackers etc; issues like downloading SW upgrade, or a        new application, to many streetlights should be automatically        scheduled in order to avoid wireless communication congestion        yet ensure that each relevant lighting processing element was        properly downloaded    -   Management SW is Cloud-based, or running on local desktops etc    -   Allowing certified users, including 3rd parties, to simulate        functions like: the lighting grid or network, simulate power        consumption, processing elements load, memories loads, lighting        plans, patterns and schedules, longevity, maintenance, SW        upgrades-scheduling planning management etc, connectivity,        congestions and backhauls, application deployments, applications        safety, applications functional or other impact in any of said        parameters, connectivity offloading from other networks (such as        muni-WiFi, commercial cellular etc.). Simulation of the said        actions can result in graphic depiction of the performance of        the relevant network elements or in reports, etc. and lead to        performing, modifying or canceling the action.

In some embodiments, the streetlight App Engine (or by the street lightprocessor) communicates and interacts with unmanned vehicles(“autonomous vehicles”), be they terrestialor aerial (ie “drones”).Communication is performed via any wireless protocol. The streetlightprocessor can include means to interract with drones for: power,connectivity, sensory information, “docking station” or “resting area”or parking area or drone taxi dispatch station etc. (as shown in FIG.6).

For example, the streetlight may include power supply circuitry, powersupply socket which is weather resistant (water, rain, humidity,temperature, dust etc.), power supply induction surface which is alsoweather resistant, mechanical or electro-mechanical locking devicecontrolled by software, for the drone. A drone may communicate with saidprocessor, directly or via the central management unit or via anotherstreetlight processor in that mesh network, authorized, and given apermission to land on that streetlight. It may then be guided to suchlanding via GPS/GNSS or other accurate or semi-accurate satellitenavigation system, and then tuned the navigation and landing via lowcost mechanisms such as RFID or WiFi beacon, image processing by thedrone camera or similar sensor of a known or coordinate marking on thetop or side part of the streetlight (such as a clearly marked symbol,sometimes in specific colors or patterns, or a mark that changesaccording to synchronized communication and shown via LED or similarlighting patterns, etc.).

As shown in FIG. 6, the drone lands on the streetlight. Anelectro-mechanical mechanism include a sensor to sense the successfullanding. Such sensor may include a pressure sensor, proximity sensor,piezo-electrical sensor, a camera or similar electro-radiated sensor, aclose/open circuit sensor, magnetic sensor, induction sensor, etc., orseveral of them combined. Then the locking mechanism 166 (FIG. 6) isactivated by the streetlight processor to lock the drone onto thestreetlight platform. For example, the drone may contain a smallelectro-magnetic that shall turn active when landing via induction powerfrom the roof of the street light, shall turn into a magnet which shallbe pulled by another magnet turning active in the streetlight so thatthe drone is dragged or pulled by magnetic force or another electromechanical component to the proper designated spot on the streetlightroof and locked into place via this magnetic power. Any such lockingmechanism shall ensure the drone shall not fall, even when severeweather arrives such as strong winds, wind gusts, etc. Lightingprotection may also be applied via this mechanical/physical connectivityusing grounding via the streetlight pole and/or the streetlightgrounding mechanism. The drone may contain a power supply charging plugor similar mechanism, for example in its landing rods or landing gear orin its body that shall connect to a power supply connector plug on thestreetlight. The streetlight may then charge the battery of the drone.Charging may also be done via other methods, such as an induction platesimilar in principal to that of induction ovens, installed on the roof,or being the roof, of the streetlight. This induction, when the dronehas the matching magnet plate attached, may charge the drone battery.

The streetlight processor may allow connectivity for that drone, such asbackhauling traffic from it via its own connectivity, so that the dronesmay carry simpler communication devices, or not use them when inlanding, or get better connectivity when flying in urban areas wheretheir own connectivity mechanisms may be limited or offer limitedcapacity or output.

When the drone is locked or parks on the streetlight as describedherein, it may go into a standby mode. In this mode the streetlightprocessor may overtake any specific or all processing missions that thedrone processor normally performs. For example, the streetlightprocessor may inform, or confirm to, the drone air traffic control oroperator or other management system that this drone has landed and is instandby mode. It may continuously or periodically inform that systemabout the drone status, such as battery charging level, and also aboutother parameters of interest such as environmental-wind, rain,temperature, etc. When that remote system requires the drone to go backinto service it may do so via the streetlight processor, that may “wakeup” the drone by means of electrical signal on the connector or othermeans such as peeping window communication over the short range with thestreetlight, which is much more power-efficient and reliablecommunication that from the drone to its remote management system, whichat times might not even be possible.

In some embodiments of the invention the streetlight, independently orin communication with other streetlights, or with other relevantentities installed in the vicinity, or with the central management orother cloud-based or remote entities, may assist or conduct or manageair-traffic control for such drone or multiplicity of drones. It maycarry sensors that identify the drone, or identify it via communication.It may carry or include means to identify its movement in the air suchas using small radars or LIDARs etc, or to simply notify otherair-traffic control entities of the current existence of the drone inits vicinity or its air-traffic controlled area. Or, it may transmitbeacons or other communications that allow the drones to navigateaccordingly. The drone may even perform triangulation calculations ofseveral beacons arriving from several streetlights or streetlight andother beacon sources. The drone may then use the identified streetlightsto move in pre-programmed lanes or paths or directions or routes in theair, know when to turn without the need to perform complex geo-spatialor similar computations etc, reducing the requirements from itsprocessing capabilities, power supply etc.

The streetlight processor that performs this air-traffic control (or thenumber of them working together in synch and exchanging information,and/or the remote management system that performs this task withcooperation and synch or distributed with the streetlight processor),may select routes for the drones based on various parameters that may beknown to the streetlight processors and management only, and thatimprove route selection, or even enable it to be optimized to certaintarget functions. For example, it may consider human density,distribution and location below the various possible drone routes frompoint A to B as measured by the sensors connected to the streetlightprocessors network or placed on them. It may then select the route thatpasses above areas with fewer, or more pedestrians or crowd gathering,or time it so that for example it goes over a cross road areas wherepeople at rush hour may crowd for a traffic light to change to green tothe moment when it changes to green and the people are no longerwaiting—for a very precise period/duration/interval. It may alsoconsider environmental conditions as measured by the other sensorsconnected to the network of streetlights or placed on them, for examplewind (strength, directions, gusts etc), heavy rain, lighting etc. It maythen select the route that best utilize wind directions and/or gusts.This is especially important in urban environment where high-risebuildings and other architecture structures may result in “wind tunnels”etc, and this may vary over short and longer time periods, such as timeof day, seasons, etc. The processor may prioritize some droned overothers, such as according to the drone parameters (e.g., dimensions,weight, etc.), their operators (for example commercial vs public safetyor police), missions (such as emergency vs lower-delay), service levelagreements and commercial terms (such as high-paying vs low-paying orothers).

These mechanisms in the invention, each one of them and all of themtogether, shall greatly increase the usability of drones to be operatedin an independent unmanned way, prolonged over time, automated, loweroperation cost, increase human and environment safety, and increase thetype of missions and volume of air-traffic possible by drones in urbanor otherwise dense areas. The invention allows drones to fly or beoperated longer without the need to return to a base, to replacebatteries, to fly low and land on surfaces that are at dangerous humanproximity hence so overall danger from drones to humans and property isdecreased. The drones can land on any allowed/authorized streetlight,decreasing their “air mileage” overhead and wasted time which are due tothe current need to fly back to their operator, to depend on suchoperator or limited designated locations for charging-a limitation whichalso decreases safety and increases density in such designatedlocations, if such exist, such as designated air-fields/strips formultiple drones. Instead, any streetlight may turn into a temporary oreven emergency landing spot, with or without power charging the drone,allow connectivity with it, coordinate the air-traffic control of manysuch drones etc.

In some embodiments of the invention drones provide connectivity tostreetlights not having such backhaul connectivity. Such a configurationthus provides a relay or ad-hoc network connection to the streetlightprocessor via its wireless communication module. The drones can “carry”software, which is downloaded download to a streetlight when the droneapproaches a streetlight and/or upon landing thereon, for streetlightsthat are normally, or accidentally, not connected to the backhaulinternet or cloud. In this way, a visiting drone provides networkconnectivity to streetlights that don't have, or don't need constantcontinuous connectivity. A visiting drone can thus provide regular orrandom connectivity to streetlights that collect metering or other dataand telemetry collected over time by such streetlights processors fromtheir own sensors and processor(s) or from proximal sensors/processors,such as, but not limited to: home power and water meters. Drones canland on the streetlight and physically connect with it, or dronescommunicate with the streetlight wirelessly such as over WiFi—as shownin the figures.

In embodiments of the current invention, the streetlight provideslighting to drones, such as when a drone or remote control managementrequests to light an area for an array of drone missions, such as butnot limited to: search and rescue; inspection (such as power-lineinspection or ground traffic management, or window or otherinfrastructure inspection), and photography (eg cinematography,cartography). The drone or management entity communicates with thestreetlight processor and instructs it where to direct the lighting, atwhat volume/power, color, and other patterns, timing, duration, etc. Thedrone and/or management entity performs calculation to ensure that thesafety streetlight is not impacted, meaning: lighting for traffic and/orpedestrians is continuously and sufficiently provided at the desiredtime. Lighting for such drone's missions may be coordinated and providedby multiple streetlights, respectively calculating the right lightingportion, or beam, at the right time and to the right location and angleas calculated by respective street lights and/or by the centralmanagement entity.

In other embodiments of this invention the streetlight pole may beequipped with means, mechanical, electrical and software, to allow adrone to deposit a package, to lower it to the ground by means such asexternal or pole-internal elevating device, to lock the package so thatonly authorized person may gain access to it, to receive an authorizedpackage from an authorized person by acting as an automated post-office,to elevate this package up for the drone to pick it up from thestreetlight, to communicate the status of such process with remotemanagement systems and receive relevant communications and instructionsfrom it, etc.

It will be appreciated that the above descriptions are intended only toserve as examples, and that many other embodiments are possible withinthe scope of the present invention as defined in the appended claims.

1. An outdoor luminaire device comprising: at least one light-emittingdiode (LED) lamp, a communication module configured to communicate witha drone, a drone docking station configured to dock the drone, and acontroller configured to: control the at least one LED lamp according toat least one of a desired functional mode or based on the communicationwith the at least one drone, and control the drone docking station so asto dock the drone.
 2. The outdoor luminaire device of claim 1, furthercomprising an App Engine configured to: download a software application,and run the downloaded software application to at least one of: controlthe drone docking station so as to dock the drone, and cause thecontroller to control the at least one LED lamp based on thecommunication with the at least one drone.
 3. The outdoor luminairedevice of claim 1, further comprising a beacon configured to send one ormore electromagnetic signals to guide the drone.
 4. The outdoorluminaire device of claim 1, wherein the controller is configured tocontrol the at least one LED lamp to generate a marking detectable bythe drone to guide the drone.
 5. The outdoor luminaire device of claim1, further comprising a sensor configured to sense that the drone haslanded on the drone docking station, and wherein the drone dockingstation is configured to alternately lock and release the drone andwherein the controller is configured to control the lock and release ofthe drone.
 6. The outdoor luminaire device of claim 1, wherein thecontroller is configured to control one or more illumination parametersof the at least one LED lamp in accordance with drone illuminationrequirements.
 7. The outdoor luminaire device of claim 6, wherein thecontroller is configured to control the one or more illuminationparameters of the at least one LED lamp in coordination with at leastone of controllers of other luminaire devices or a main control andmanagement subsystem.
 8. The outdoor luminaire device of claim 1,wherein the drone docking station comprises a power interface connectedto a power supply to charge one or batteries of the drone.
 9. Theoutdoor luminaire device of claim 1, wherein the controller isconfigured to identify the drone based on at least one of signals beingreceived from one or more sensor connected to the controller or thecommunication of the drone.
 10. The outdoor luminaire device of claim 1,further comprising an elevator, wherein the controller is configured tocontrol the elevator to: receive a package from the drone being dockedon the drone docketing station, lower the package to the ground level,lock the package, and release the package upon identification of anauthorized person.
 11. The outdoor luminaire device of claim 1, furthercomprising an elevator, wherein the controller is configured to controlthe elevator to: receive a package from an authorized person uponidentification of the authorized person, elevate the package to thedrone docketing station level, ick the package, and cause the dronebeing docked on the drone docketing station to receive the package. 12.The outdoor luminaire device of claim 1, comprising or connected to oneor more sensors configured to measure one or more parameters, andwherein the controller is configured to perform one or more actionsbased on the one or more measured parameters.
 13. An outdoor luminairesystem comprising: a first plurality of drones, and a second pluralityof outdoor luminaire devices each according to claim 1, being arrangedin an outdoor area.
 14. The outdoor luminaire system of claim 13,wherein the controllers of at least a portion of outdoor luminairedevice of the second plurality of outdoor luminaire devices areconfigured to control an air traffic of at least a portion of drones ofthe first plurality of drones.
 15. The outdoor luminaire system of claim14, wherein the controllers of at least a portion of outdoor luminairedevice of the second plurality of outdoor luminaire devices areconfigured to control the air traffic of at least a portion of drones ofthe first plurality of drones in coordination at least one of a maincontrol and management subsystem or with each other.
 16. The outdoorluminaire system of claim 13, wherein the air traffic control comprisesselection of routes for at least a portion of drones of the firstplurality of drones.
 17. The outdoor luminaire system of claim 16,wherein the air traffic control comprises prioritization of at least aportion of drones over other drones of the first plurality of drones.18. The outdoor luminaire system of claim 13, wherein the at least aportion of outdoor luminaire devices of the second plurality of outdoorluminaire devices being configured to transmit navigation beaconsignals, and wherein one or more drones of the first plurality of dronesbeing configured to receive the navigation beacon signals and navigatein the outdoor area based on the navigation beacon signals.
 19. Theoutdoor luminaire system of claim 13, wherein one or more drones of thefirst plurality of drones being configured to connect one or moreoutdoor luminaire devices of the second plurality of outdoor luminairedevices to a network using their respective communication modules. 20.The outdoor luminaire system of claim 13, wherein at least a portion ofdrones of the first plurality of drones being configured to navigateusing global navigation satellite system (GNSS), wherein at least aportion of the outdoor luminaire devices of the second plurality ofoutdoor luminaire device being configured to guide at least a portion ofdrones of the first plurality of drones to landing on their respectivedrone docking station by performing at least one of: sending one or moreelectromagnetic beacon signals, and controlling their respective LEDlamps to generate markings detectable by the drones.